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Preface 


The Materials Laboratory of the Air Force Wright Aeronautical 

Laboratories (AEWAL/ML), Wright-Patterson Air Force Base, Ohio performs 

a myriad of experiments in which a great amount of data is being 

gathered. In sane of these experiments, data gathering still involves 

manual interaction and/or the use of strip chart recordings or paper 

tapes. Digitizing the strip charts so that further manipulations of the 

\ 

data can be performed is laborious and prone to errors. To automate the 
data collection for a wide range of experiments, the Materials 
Laboratory purchased the necessary hardware ccrrponents. It was about 
the time when all the ccnponents were received that I was assigned to 
the Carputer Activities (koup, which- oversees the data automation needs 
of the Laboratory. I was assigned the project, and subsequently turned 
it into a thesis topic. 

I wish to thank my supervisor and my Laboratory sponsor, Capt 
William H. Walker IV, for letting me, in fact encouraging me, to work 
on the project with a view towards writing it as a thesis. Acting as 
the critical user, he also provided helpful information when I needed it 
most. Special thanks goes to Colonel James P. Rutledge, my advisor and 
software engineering tutor, for his technical advice and direction; to 
the other members of the thesis ocmmittee. Major Alan Ross and Professor 
Thomas Hartrun, for their most welcome critique and Garments; to Dane 
Hanby and Frank Beitel of the University of Dayton Research Institute, 
for providing assistance when seemingly trivial hardware and software 
matters escape me; and to A1C Chung Kong, for the "nuts and bolts" 
operation of the system. Most irrportantly, I wish to thank my wife, 
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Daisy; our children, Joan and Dennis; my in-laws. Jack and Lydia 
Yacas, without whose love, patience, understanding, support and 
encouragement, my efforts would surely have come up short and this 
project would not have come to fruition. 
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Abstract 


A portable, automated, generalized experiment control and data 
acquisition system was developed for the Materials Laboratory to fulfill 
some of its data automation needs. The system is portable in that all 
hardware components fit in an aluminum carrying case, except for the 
terminal which is separate. The need for portability requires the 
program to be loaded from the terminal minicassette tape. The collected 
data is likewise dumped into the minicassette. 

The hardware components were already procured before actual 
software development was begun, which included an extensive software 
requirements definition phase. The Air Force method of requirements 
definition, IDEFO, was used to model the software requirements. It 
involves a top-down approach to development. Hie model, thus 
diagrammed, provided the general structure frcm which the program itself 
was written. Structured code and anple documentation form the basic 
programming technique implemented. The program is currently 
operational, the system having been utilized in two actual experiment 
set-ips. The requirement to load the program frcm the minicassette was 
not satisfied, however, because of some loader error. The program can 
presently be loaded using a floppy disk system. 
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I. Introduction 


Background 

Hie Materials Laboratory of the Air Force Wright Aeronautical 
Laboratories (AFWAL/ML), Wright-Patterson Air Force Base, Ohio, performs 
a variety of experiments aimed at understanding the properties of 
materials. These experiments can be categorized into two basic s: 
(1) those that have dedicated, automated data acquisition systems 
designed (built) into them, and (2) those where data is gathered by 
manual observation and measurement or by using strip chart recorders. 
Both types of experiments have their limitations. Despite great strides 
in the reliability of automated data acquisition systems, these systems 
occasionally fail. Depending on the severity of the breakdown, it could 
take some time before the experiment can be continued or started again. 

Data collection by manual observation and measurement is tedious 
and inherently inaccurate. Likewise, the use of strip charts can be as 
inaccurate if human interaction is required to read data off the charts 
(digitize) for further processing in order to determine the material 
property of interest. For instance, areas under strip chart curves are 
usually of high interest and must be manually determined. 

The benefits of automating the data acquisition process for 
experiments requiring manual interaction are obvious (with due regard to 
the reliability problem mentioned above). This will not only free the 
experimenter to do other tasks but will also increase the speed and 
accuracy of the process. Hcwever, since experiments requiring manual 
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interaction are normally very highly specialized and are short-term or 
one-time in nature, the cost of procuring an automated system for each 
experiment is enormous. A portable, general, automated data acquisition 
system is therefore required. This general system can also serve as a 
back-up system to experiments of type (1). 

Hie portable data acquisition system can additionally be used as an 
experiment controller, albeit a very primitive one indeed. By 
monitoring the values of a certain specified measurement, an appropriate 
predetermined action can be taken when these values get out of a given 
range. This action can be a message to the operator or it can be an 
automatic adjustment of an experiment parameter that the automated 
system controls. 

It is not usually sufficient to proceed directly into designing a 
hardware and/or a software solution as soon as a need for an automated 
system is identified. Nor can the hardware and software efforts be 
totally removed from one another. Whereas hardware considerations may 
sinply involve purchasing off-the-shelf equipments, software development 
involves more than sinply designing the algorithm and then coding it in 
a suitable programming language. Too many software projects have 
encountered enormous cost and time overruns because the software 
requirements were never really defined. In fact, software costs have 
become a sizable portion of the Air Force's budget (Ref 10:12). 

Hie Air Force, through numerous reviews and specification 
requirements, has begun bo address the many phases of software 
development. These phases include system requirements definition, 
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test and 




software requirements definition, design, code and debug, 
integration, and operations and maintenance (Ref 2:1226-1227). Still, 
projects with varying degrees of diffir ulty meeting schedule and budget 
constraints are very frequently identified. Studies made of these 
projects have shown that they are lacking in the requirements 
definitions phase of the development (Ref 10). Requirements definition 
is the process of specifying what problem is to be solved. Obviously, 
without a clear understanding of what the system is to perform, the 
chances of something going wrong are increased tremendously. Inoonplete 
or erroneous solution to a muddled requirement or correct solution to 
the wrong problem are the usual results. 

Statement of the Problem 


The purpose of this study is to develop the software required to 
inplement the portable, automated, generalized experiment control and 
data acquisition system. 

Constraints/Assunptions 

Although the software to be developed must be applicable to most of 
the laboratory's data acquisition needs, the Materials Laboratory has 
requested that the software be initially tailored for four of its 
projects, namely: (1) laser effect testing, (2) polymer cure kinetics, 
(3) liquid chromatography, and (4) mechanical testing. (See Chapter 
III, for further discussion on these projects.) This will limit the 
number of users from which input data to the software requirements 
process nust be gathered. This is important because there must be 
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common agreement among parties on the set of specifications to be 
developed. 


In addition, AFWAL/ML has already procured an LSI-11 microoonputer 
system and associated instrumentation to inplement the hardware 
requirements. This constitutes an additional constraint because the 
software bo be developed must be compatible with this microoonputer 
system. 

Approach 

Hie software requirements definition for the portable, automated 
generalized experiment control and data acquisition system are generated 
using the initial version of the Integrated Ccrputer-Aided Manufacturing 
(ICAM) Definition Method (IDEFO), developed for the Air Force by 
SofTech, Inc. This technique, which is the Air Force version of the 
Structured Analysis and Design Techniques (SACfT), involves modeling a 
system by means of a collection of diagrams showing things (objects or 
information) and activities (performed by men or machines). Hie model 
distinguishes what functions the system must perform from how the system 
is built bo acconplish those functions (Ref 5). 

Hie design of the software generally follows the 
caiposite/structured design techniques advanced by Myers in reference 9. 
Where deemed necessary, deviations are made and duly noted, giving 
specific reasons for such deviations. Hie code and debug, test and 
integration, and operations and maintenance phases of the development 
are in accordance with prevailing Department of Defense and/or Air Force 




standards, including documentation standards, on a lot smaller scale 
(Itef 3). 

Plan of Development 

The requirements definition for the portable data acquisition 
system is presented in Chapter II. The software requirements definition 
with enphasis on the functional specifications is discussed in Chapter 
III. Chapter IV presents the formal functional specifications for the 
system. These specifications are in the form of activity and data 
models. Design of the software is the topic of Chapter V and the 
remaining development phases are included in Chapter VI . Chapter VII 
contains the summary and recommendations. A typical portion of the 
code, with enphasis on the documentation, a users manual and a printout 
of a sanple session at the portable terminal are placed in the Appendix 
section. 
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II. System Requirements Definition 


Introduction 

Requirements definition enccrpasses all aspects of system 
development prior to actual system design, everything necessary to lay 
the groundwork for subsequent stages in system development. It deals 
with three subjects: 1) context analysis, which deals with the reasons 
why the system is to be created; 2) functional specification, which is 
a description of what the system is to be, in terms of the functions it 
must accorrplish; and 3) design constraints, which includes a suninary of 
conditions specifying how the required system is to be constructed and 
implemented (Ref 14:1-2), For this study, context analysis was 
discussed in Chapter I; functional specification is presented in a 
later section of this chapter, following the discussion of the design 
constraints. 

Design Constraints 

In carder to take advantage of the Laboratory expertise on Digital 
Equipment Corporation (DEC) LSI-11 systems, the Materials Laboratory 
chose to base the portable, data acquisition system on the LSI-11/2 
microprocessor. The other hardware ccnponents must, of course, be 
conpatible with this microprocessor. A block diagram of the portable 
system is shown in Figure 1. The major component parts include, in 
addition to the LSI-11/2 microprocessor, a digital-to-analog and 
analog-to-digital converter (ADAC 1030), a miltiplexer/anplifier board, 
a clock board, and the operator's terminal (Miniterm 1205). A ccnplete 
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parts listing for the system is given in Table I. 


Table I. Portable Data Acquisition System Carponents 


Part/Description 

I£I-ll/2 Central Processing Unit 

32k RAM Memory 

Backplane/Card Guide Assembly 
Power Supply 
A/D and D/A Converter 
Parallel I/O Port 
Serial I/O Port 
Floating Point Chip 
Portable Terminal 
Multiplexer 

Instrumentation Anplifier 
DC/DC Converter 
Carrying Case 
Clock Board 


Manufacturer 

Part Number 

DEJC 

KDll-HA 

DEC 

MSV11-DD 

MDB Systems 

MLSI-BPA84 

Standard Power Inc. 

SPS 130D 5/12 

ADAC Corporation 

ADAC 1030 

DEC 

DKV11 

DEC 

DLV11 

EEC 

KEV11 

Oanputer Devices 

Miniterm 1205 

Harris 

HI3-0506-5 

Analog Devices 

605K-100 

Analog Devices 

940 

Zero Corporation 

110-P6 
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ISI-11/2 . The central processor for the portable data acquisition 
system is DBC's LSI-11/2 (part number KDll-HA). It is a microprocessor 
with reasonably fast speed and has 32K words (16 bits) of memory. It 
supports the basic PDP-11 instruction set and, with the optional 
Floating Instruction Set (KEVll) (which was also purchased), can perform 
floating point arithmetic operations. 

ADAC 1030. The ABAC 1030 is a 16-channel analog-to-digital plus an 
additional two-channel digital-to-analog converter. It is configured to 
have fully differential analog inputs with a range of -10 volts to +10 
volts. This configuration is junper selectable and was chosen to 
accommodate the more common range of analog output signals found in 
laboratory devices. The weaker signals (millivolt range) are anplified 
before they are fed to the converter. Likewise, the selected output 
range of the digital-to-analog converter is -10 volts to +10 volts. 
Selection is also through the use of junper wires. 

Multiplexer/Anplifier . The multiplexer/anplifier is comprised of a 
multiplexer, an instrumentation amplifier, and a DC/DC converter. The 
particular circuit that is used in this project was designed and built 
by Dane Hanby of the University of Dayton Research Institute and is 
shown in Figure 2. The output of this circuit is fed directly to the 
ADAC A/D converter, using the irput pins for channel 1 as shown in 
Figure 3. 

Clock Board . The clock board provides the timing interrupt circuitry 
for the system. It consists of a crystal oscillator with TTL output, 
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Figure 2. Multiplexer/Amplifier Circuit Diagram 







three synchronous decade counters, and a line driver. The diagram 
(Figure 4) shears the inter connections among the circuit parts as well as 
the interface to the system. This circuit was designed by Tern Wood 
while he was working for the University of Dayton Research Institute. 

Miniterm 1205 . This is the portable terminal that allows operator 
communication with the microccrputer system. It provides for Standard 
RS232 interfacing, has a built-in acoustic coupler capable of 300 or 
1200 baud transmission rates, and includes 8K of RAM memory (expandable 
to 32K) making it possible to edit data off-line perhaps after or in 
between experiments. It also includes a minicassette tape drive to 
provide extra storage of special programs or historical experiment data 
of up to 68,000 characters per minicassette. 

The entire hardware of the system is contained in a single carrying 
case. The operator's portable terminal is separate and is 
self-contained. Set-up requires: 

a) connecting power cord to 110 VAC; 

b) connecting cable between the portable terminal and the 
hardware case; 

c) wiring analog in/analog out experiment lines to proper 
terminals on terminal strip of hardware case; 

d) for connection to the remote host conputer, establishing 
communication line and placing telephone receiver in 
acoustic coupler receptacle. 
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Figure 4. Timing Interrupt Circuit 







Functional Specifications 

As mentioned in Chapter I, the Materials Laboratory's objective is 
to assemble a general, portable data acquisition and experiment control 
system to support mission essential part-time and short-term projects. 
This system is to operate in two basic inodes: 1) data 
acquisition/process control mode, and 2) data communication mode. 

In the data acquisitioryjprocess control mode, the system is wired 
to the experiment and the proper data acquisition and control program is 
loaded from the operator terminal's cassette tape. Program parameters 
are set by the user from the terminal keyboard. Control of the 
eaqperiment is initiated and data acquisition is started. After data 
collection is completed, data is transferred from system memory to 
cassette tape and/or to the appropriate host computer as explained in 
the data oomnunication mode. 

In the data communication mode, the user transmits data stored in 
memory or cassette tape from the Miniterm to the computer which will 
perform data reduction and/or provide long-term storage. This mode is 
also used to transfer the absolute code for programs from the PDP-11/03 
development system to the portable system (cassette tape) or programs 
from cassette tape to memory. 

Software development was performed on the PDP-11/03 development 
system and transferred to cassette tape for portability. Note that 
initial program checkout may be performed at the development system 
site, with all the system interfaces actually available. 
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Suninary 


This chapter covered the functional specification and design 
constraint aspects of system requirements definition. The context 
analysis, it was mentioned, has already been discussed in Chapter I. 
The rest of the thesis will new focus on the software development for 
the general, portable data acquisition system. 
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III. Software Requirements Definition 


Introduction 


Neglect of the requirements definition phase has been blamed, along 
with other causes, for excessive cost and schedule overruns. In 
addition, the elimination of this important step often results in an 
incomplete documentation package which, in turn, contributes 
significantly to cperations/maintenance problems later in the software 
life-cycle. 

The software for this thesis was generated to implement the 
portable data acquisition system, the hardware component parts of which 
have already been procured by the sponsoring laboratory. The 
procurement of the hardware components represents a software design 
constraint inasmuch as the software product must be compatible with the 
procured hardware system. Also, while there are numerous packaged 
routines available for such systems (LSI-11 systems), the portability 
requirement represents an additional design constraint, because not all 
these routines are usable for stand-alone systems. This chapter 
describes the context analysis and the functional specification aspects 
of the software requirements definition. 

Context Analysis 


The software requirement is for the implementation of the portable 
data acquisition system. Four Materials Laboratory projects were 
initially identified as possible applications for this system. These 





are 1) laser effect testing, 2) polymer cure kinetics, 3) liquid 
chromatography, and 4) mechanical testing. In order to develop a set of 
software requirements, we nust examine the individual requirements of 
these four exanple projects. 

Laser Effect Testing . This experiment determines the thermal effects of 
firing a laser beam at a given material specimen. Several thermocouple 
beads are positioned in a sanple to record the temperature profile of 
the material as it is burned. Presently, the signals fran the 
thermocouple wires are recorded on a VISIOORDER chart. In order to 
perform mathematical manipulations of the collected data, the charts 
must be digitized. At most ten signals are monitored for each 
experiment run. The run itself takes approximately ten seconds, with 
the laser beam normally on for only 0.3 second. 

There is a short period after the run is started that no meaningful 
data is available for collection. The start of the data collection 
process thus requires the detection of a START signal, which is not 
presently available. One hundred data points per thermocouple wire meet 
the digitizing requirement; which means approximately one thousand data 
points mist be recorded every ten seconds. 

Polymer Cure Kinetics . The Polymer Branch performs polymer cure 
kinetics using thermal analysis instrumentation. A polymer sanple is 
heated at a given rate and the terrperature of the cell in which it is 
placed is recorded at specific time intervals, usually on the order of 
one second. Presently, this tenperature data is recorded on paper tape 
and, for back-up and further oortparison, on a strip chart. For further 


17 


data manipulations, the paper tape is read into the host ocnputer where 
the necessary application programs are installed. The data is plotted; 
the area under the curve is determined; and after a series of curves, a 
time-tenperature-degree-of-cure relationship is established for the 
polymer. 

Five different heating rates are used in this experiment (80, 40, 
20, 10, and 5 degrees Kelvin per minute) to get to a cell tenperature of 
400 degrees Kelvin. Between 350 and 500 tenperature readings are 
collected per scan which means that, for the shortest experiment scan 
(five minutes), at most one hundred of these readings are recorded per 
minute. 

Liquid Chromatography . High performance liquid chromatography is used 
in the Materials Laboratory for research and routine quantitative 
analyses. A strip chart recording is the output medium used for 
collected data. Reading the charts and manually determining the area 
under each "peak" in the curve (extrapolated accordingly if peaks 
overlap) is the standard manner in which the relative amount of each 
sanple's oonponents is measured. A normal run takes approximately two 
minutes and 200 data points render satisfactory results. 

Mechanical Testing . The Metals Behavior Branch performs experiments to 
study the effect of cracks on t h- strength of materials. Sanples are 
placed in a loading frame in which a variable load can be exerted on the 
sanple. The sanples are notched or cut perpendicular to the axis of 
loading to promote cracking. The rate of crack propagation is 
determined in part by the anplitude of the load being applied. These 
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experiments sometimes take an inordinate cmount of time because the 
cracks do not propagate very fast; or, conversely, end abruptly because 
the samples fracture easily with the applied load. 

A typical crack growth experiment usually takes between eight hours 
to almost three weeks. Twenty blocks of crack growth data, 
corresponding to twenty different temperatures, are gathered. Each 
block contains 50 to 150 data points. These data points are a function 
of the specimen geometry, the applied load, crack length, and time. The 
relationship between these factors is predetermined and must be 
maintained through the experiment run. Since the specimen geometry 
remains essentially constant, the applied load must be "controlled" 
according to the rate of crack propagation (change in crack length over 
time). This control requirement is normally performed at one- to 
ten-minute intervals. 

Because of the time element involved and the inherent inaccuracies 
of the manual process, the need is clear for an automated system. 
Automating each experiment's data collection process according to its 
individual requirements is economically unfeasible. Therefore, any 
automated system to be developed must be general enough to accommodate 
at least the range of experiments discussed above. It must also be 
portable if it is to be easily moved from one experiment location to 
another. 

Projects similar to those mentioned above abound in the Laboratory 
and can be easily adapted to utilize a portable, automated data 
acquisition system. In addition, the dynamic nature of the Laboratory's 
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conmitment to materials research makes it very desirable to build such a 
general system. 

Functional Specifications 

Any system developed must be a general-application system. It must 
provide the user the opportunity to define his particular experiment's 
data collection and experiment control needs. The capability to record 
data at any given time is needed in the system. In addition, there is a 
need, as in the laser experiment, to provide a mechanism to start data 
collection separately from the start of the experiment; that is, to 
take action depending upon a given condition. The mechanical testing 
experiment exhibits another sort of need: the ability to provide 
feedback to the experiment to control a particular parameter. These 
needs make up the functional specifications discussed below. 

Define Experiment . When the system is first put into operation, a menu 
of all the valid commands, including their descriptions, is shown to the 
user. Among these is a DEFINE oormand that allows the user to define 
the data channels he will use in collecting data from his experiment. 
This command is appropriately labelled as the first command given in 
normal system operation. Up to three channel files can be defined: 
channel schedule file, channel dependency file, and channel control 
file. A channel schedule file must always be defined; the other two 
are defined only as required. 

The channel schedule file consists, as a minimum, of the 
information required to collect data at sane indicated times. This 
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information may include the initial read time and the time interval 
between reads for each channel defined. The channel dependency file, on 
the other hand, is defined for experiments where certain information 
does not become meaningful until same condition arises; for exanple, a 
voltage reading in an experiment may be meaningless unless the 
temperature reading in channel 1, say, is over 350 degrees Farenheit 
when certain chemical reactions are known to take place. The dependency 
file requires the channel (number) that must be monitored for the 
condition, the condition itself, and the channel that must be read when 
the condition is satisfied. 

A channel control file is needed when the system is to be also used 
as an experiment controller. In this configuration, one or more of the 
scheduled channels (defined in the channel schedule file) may be 
monitored and their values aonpared against a given range. One of two 
actions is taken when this value does get out of range: a message is 
printed on the operator's terminal or a specified output channel is 
adjusted accordingly. The control channel file therefore includes the 
low and high values of the required range, the appropriate action when 
the control channel value gets out of this range, the output channels 
when the control channel value is below and over the range, 
respectively, and the message text, if operator interaction is required. 

For each of the above channel definitions, the user is given the 
opportunity to check his entry lines and modify them as he wishes. 
These change options include the ability to change any single line, 
change all lines, add a new line, or delete an existing line. 
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Set/Change Parameters . When the portable automated data acquisition 
system is also to be used as an experiment controller, a function to 
set, reset, or change experiment parameters is required. This mechanism 
can either be manual or automatic. The oontrol channels are monitored 
and their values continually ocrrpared against given ranges. When a 
channel reading does get out of its specified range, the proper 
adjustments must be made. 

Acquire Data . Within its speed capabilities, the system must be able to 
sanple the analog signals present on the defined data channels and 
convert these into digital data. These read times are available from 
the channel schedule file and readings must be made as closely as 
possible to the indicated read times. Once a scheduled channel is read, 
its next read time is Lpdated using the time interval between channel 
reads. If there is enough time before the next scheduled read time, the 
channel dependency file is also checked. Any dependent channel that has 
its dependency conditions satisfied must be read, and its read time 
subsequently updated. If a oontrol channel file is present, it, too, 
must be checked. 

Store Data . If, after reading a scheduled or a dependent channel, its 
internal storage capacity is reached, the system must be able to dunp 
whatever data has been collected to sane permanent storage medium. Data 
collection can then proceed as before. 

Depending cn the time interval between scheduled channel reads, 
sane data may be lost while storing one batch of data into the 
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terminal's recording equipment- The operator is given the option to 
t ransmi t the acquired data before the system's interned storage (memory) 
Is full/ so that shorter, but obviously more, time intervals will be 
spent transferring his blocks of data. 

Summary 

this chapter discussed the context analysis step in the software 
requirements definition phase. It also presented the software 
functional specifications in a general, informal manner. Software 
functions included defining the experiment, controlling parameters, 
acquiring data, and storing data. These specifications will now be 
formally presented in the next chapter. 
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IV. Functional Specifications 


Introduction 


The formal functional specifications for the system are developed 
using the initial version of ICAM Definitial Method (IDEFO). Its 
fundamental concept is a combination of structured analysis concepts. 
Two of these concepts are to understand a system by creating a model 
that graphically shows things (objects or information) and activities 
(performed by men or machines) and to structure a model as a heirarchy 
with major functions at the top and successive levels revealing 
well-bounded details. In IDEFO, this model is in the form of diagrams 
which are oonposed simply of boxes and arrows, boxes representing 
activities and arrows representing things (Ref 5). 

Creating the diagrams for the proposed data acquisition system is 
facilitated by the discussion of the major functional requirements in 
the previous chapter. This chapter presents the subdivision of these 
functions into smaller subfunctions, in the form of diagrams, which make 
up the model for the system. 


Activity Model 

Ihe initial step in the discussion of the activity model is to 
present the model in the form of a node index. Here the relatonships 
'mcng the different nodes ocrprising the model is exposed, and 
understanding the model is enhanced. This node index, showing the order 
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of the node diagrams, is shown in Table II. The detailed functional 
requirements are given in the following diagrams, starting with node 
A-0, Manage Data Acquisition. 

Table II. Node Index 

AO Manage Data Acquisition 
Al Define Experiment 

All Determine File Type 
A12 Create Schedule File 
A13 Create Dependency File 
A14 Create Control File 
A2 Set/Change Parameters 
A21 Check Control Value 
A22 Determine Correct Setting 
A23 Automatically Adjust Channel 
A24 Manually Set Parameter 
A3 Acquire Data 

A31 Read Scheduled Channel 
A32 Update Schedule File 
A3 3 Read Dependent Channel 
A34 Update Dependency File 
A4 Store Data 

A41 Generate Start-Receive Signal 

A42 Receive Data 

A43 Generate Stcp-Receive Signal 







The portable data acquisition system is able to conduct the 
experiment and collect data through commands given by the operator. 
Inputs include operator information provided via his terminal and the 
analog voltages supplied from the experiment output lines. Messages may 
be given to the operator for proper (corrective) actions, while the 
collected data are written cnto a minicassette tape available on the 
operator's portable terminal. 
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The acquisition of data and the control of the experiment consists 
of four major functions: defining the experiment in terms of the 
sartpling strategy for the selected data channels (1); setting the 
necessary equipment parameters to the desired values, whether manually 
or automatically (2); actually reading the data within the specified 
time frame (3); and storing the data for transfer to the mainframe 
ccnputers for archiving and/or further reduction (4) . Define Experiment 
provides channel information to both the Set/Change Parameter and the 
Acquire Data functions: to make sure that the channel parameters are 
within the correct bounds and to provide the proper time frame for 
reading the channels, respectively. Acquire Data is also dependent upon 
the generation of the proper signal in Set/Change Parameter. When data 
gathering is oonplete, when system memory is full, or when directed by 
the operator, the data collected is stored by dunping it to the portable 
terminal's minicassette. 
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Define Experiment provides the necessary sampling strategy and 
control information in terms of three channel files. Three subordinate 
functions create these files: Create Schedule File (2), Create 
Dependency File (3), and Create Control File (4). While the contents of 
these files are different, the manner in which they are created is not. 
Once a file type is determined (1), the file is built up by having the 
operator type in a line of information according to the format shown in 
his terminal. 


31 




32 


Figure 8. Node A2, Set/Change Parameter 















One of the files generated by the Define Experiment function is a 
channel control file. This file is checked every time a control channel 
is read (1). This value may or may not be within the correct range for 
proper controlling of the experiment (2). If not, a parameter 
associated with this channel must be properly adjusted, either 
automatically (3) or manually (4). 
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Figure 9. Node A3, Acquire Data 
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Data is acquired by reading the scheduled channels during the 
appropriate times (1). Other channels rray also have to be read during 
this time frame, if certain conditions are met. These are called the 
dependent channels (3). The schedule file and the dependency file are 
updated (2 and 4) during this activity to reflect the next scheduled 
time when these channels are to be read again. 

The analog signals are experiment output signals that nust be 
monitored. When these signals are weak such that they are not capable 
of driving the analog-to-digital converter, they are first anplified to 
the proper range. This is a hardware function and is not shown in the 
diagram. 
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Once data acquisition is completed, or when the system memory is 
full, or when directed by the operator, the data is dunped frcm the 
system memory to the minicassette available on the operator's terminal. 
This requires a Start-Receive signal (1) to activate the tape drive 
mechanism for the proper receipt of data (2). A Stop-Receive signal (3) 
is generated when all of the data is received. Care mast be taken in 
order not to overflow the capacity of the minicassette. As much packing 
of integer data as possible must be incorporated into the program for 
maximum use of the minicassette, especially when a lot of data has to be 


taken. 







Summary 


This chapter presented the formal functional specifications for the 
portable data acquisition system in terms of the diagramming conventions 
of IDEFO. The relationships among the different nodes and the flow of 
data between them are new evident. These diagrams provide a very good 
foundation towards designing the software. A set of specifications has 
been developed against which the software can be compared. 
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V. 


System Design 


Introduction 


A principle of structured analysis states that an exposition of a 
certain problem can be performed recursively through a systematic 
breaking down of the subject natter into six or less component parts 
(Ref 5:Chapter 2 , 2 - 2 ). It is a gradual, top-down decomposition 
approach, leaving nothing out at any stage. The end result is an 
analysis expressed in well-structured diagrams that enhance an 
understanding of the requirements for the solution of the original, 
complex problem. These requirements can then be translated, in a 
rigorous, organized, efficient and, above all, understandable fashion, 
into actual system design. 

The diagrams of the previous chapter lend themselves well bo the 
design of the software for the portable data acquisition system. The 
four major functions are grouped into "run preparation" and "run 
experiment" categories according to their time of occurrence. Define 
Experiment falls into the first category, as well as the initial setting 
of experiment parameters. Data collection and any follov-on 
setting/changing of parameters occur during the actual running of the 
experiment. Data storage (dunping into tape) may be done while the 
experiment is running; usually, however, it occurs after the experiment 
has terminated. 

Using the same heirarchical approach as IDEFO proposes, the basic 
functions are designed and the results presented in this chapter. 
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Structure Charts 


The overall structure of the software system is shown in Figure 11. 
Each box represents a (program) module; that is, a collection of 
executable program statements which is a closed subroutine, can be 
called from any other module in the program, and has the potential of 
being independently compiled (Ref 9:11). Note the striking similarity 
between the program structure and the functional specification diagrams 
of the previous chapter. This is no coincidence. The ultimate 
objective of structured analysis and design is to eliminate the 
ambiguities and the oftentimes random relationships between the modules 
that make up the whole program. In the structure of Figure 11, each 
module has its own particular function to perform, which is nicely 
broken down into sinpler component functions by lower-level modules 
(Figures 12-26). The lowest-level modules perform elementary functions. 

The data flow among the program modules is exhibited in tabular 
form under each decorposition figure in the manner suggested by Myers 
(Ref 9:110-121). The IN and CUT columns refer to input and output data, 
respectively; the numbers refer to the interface labels shown. An 
input datum is something whose value is significant upon entry to the 
called module whereas an output datum is something whose value is 
assigned or changed within the called module. It is therefore possible 
for a data item to be both an input and an output (Ref 9:15). 
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Figure 11. Program Structure for the Portable Data Acquisition System 
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Figure 12 Decomposition of “Manage Data Acquistion" 



Figure 13. Decomposition of Define Experiment' 
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Figure 14. Decomposition of "Run Experiment 
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Figure 15. Decomposition of 'Create Schedule File' 
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Figure 16 . Decomposition of ‘Create Dependency File' 
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Figure 17. Decomposition of "Create Control File 
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Figure 18. Decomposition of "Get Parameters 
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Figure 19. Decomposition of "Read Scheduled Channels" 
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Figure 20. Decomposition of "Read Dependent Channels 















Figure 2 1. Decomposition of "Control Experiment". 
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Figure 22. Decomposition of "Store Collected Data' 
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Figure 25. Decomposition of “Read All Channels 



Figure 26. Decomposition of "Update Read Times 


















Summary 


Hie structure of the software system was revealed in this chapter. 
The decomposition of the higher-level modules was presented and each 
module-module interface defined according to the data that flow between 
them. Against this backdrop, coding the software is made a lot easier, 
which is, not coincidentally, the next phase in the development effort. 
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VI. Remaining Development Phases 


Introduction 


With the structure of the software designed and optimized, it would 
seem that the next step is to design the logic (algorithm) of the 
modules and code it in the appropriate programming language. Myers 
advocates yet another intervening step, however, a step he calls "module 
interface design". The purpose of module interface design is to 
produce, for each module, a module interface specification describing 
precisely the function and interface of the module. The information 
needed in the specification includes the module (or entry-point) name, 
the function of the module, the number and order of the arguments, the 
input arguments (their meaning, format, size, attributes, units, and 
valid domain), the output arguments (their meaning, format, size, 
attributes, units, and valid range), and the external effects (actions 
external to the system, e.g. irput/output operations) (Ref 9:148-149), 

Ihe module interface specifications provide an excellent 
documentation mechanism, but are not included here; rather, they will 
be incorporated in the program code where they are most useful. A 
listing of the program will be submitted to the Materials Laboratory for 
inclusion in their application programs library. Future maintenance 
programmers will find this documentation very valuable and they will 
have easy access to it. 

The remaining phases of the software development for the portable 
data acquisition system are discussed in this chapter. 
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Code 


Coding the program, given a good structure, becomes almost 
mechanical (Ref 7:119). This does not mean, however, that the structure 
be followed rigidly, with no deviations. In fact, the "module interface 
design" step revealed, and the code implemented, the need to slightly 
modify the data flew as shown in the design chapter. In particular, the 
channel schedule, dependency, and control files are no longer passed 
between modules as arguments but are rather shared by modules through 
the use of named COPMDN blocks. This introduces "pathological data 
connections" (Ref 19:242) between modules which create, from a 
structured design point of view, an undesirable coupling condition. 
However, these channel files each contain a group of 
functionally-related data items and together total more than a trivial 
number of arguments to pass from module to module. And although still 
open for debate, the number of modules these files have to pass through 
makes the claim credible that this can cause a discernible effect in the 
speed of the program execution. 

The relative ease of coding the program does not inhibit one frcm 
using pre-existing modules, either. This is in fact encouraged (Ref 
9:4). In the Materials Laboratory, a number of small programs have been 
written for specific data acquisition systems. The Assembly program to 
drive the ADAC A/D and D/A converter and the clock interrupt routine are 
incorporated in the portable data acquisition software. These modules 
expect COPWON blocks for the values read fian the converter and the 
running clock time information. 
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Data Collection Algorithm . The tcp-down approach to the decomposition 
of the program modules makes it easy to understand what each module 
performs. The lowest of these modules perform elementary functions and 
are not difficult to code. The implementation of seme higher-level 
modules, however, is more conplex and needs more elucidation. For this 
purpose, the algorithm for the data collection is presented below. 

1. Scheduled channels are read ^regularly^ - as closely as possible to 
the scheduled read times. 

a. All channels are continuously scanned through the 
analog-to-digital converter. The values read, along with the time of 
this read, are placed in a buffer. A determination is then made whether 
to save this tenporary data or not. 

b. If the actual read time is within Ml milliseconds (see point 8 
below) before the scheduled read time, the data in the buffer is stored. 
If it (actual read time) is already past the scheduled read time, the 
data is also stored, in addition to checking the conditions in 2 below. 
Otherwise, the data is discarded (overwritten). 

2. If the actual read time overruns the scheduled read time, the actual 
read time is checked to see if it is within one-half the time interval 
(between scheduled reads) from the scheduled read time. If it is, the 
scheduled read time is incremented by the corresponding channel time 
interval to get to the next read time. If it is not, the scheduled read 
time is incremented by as many time intervals as necessary to get it 
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within cne-half the time interval frcm the actual read time; the 
channel values read then correspond to this updated scheduled read time, 
and normal incrementing is resumed. The skipped scheduled read times 
are sinply missed. 

3. If there is a channel scheduled to be read within M2 milliseconds 
(see point 8 below) of the actual channel read time, no dependency check 
is nade unless as specified in 4 belcw. 

4. If the time interval between scheduled channel reads is such that a 
defined channel dependency file is not being checked (there is always 
one channel or another to read within M2 milliseconds of yet another), a 
mechanism is included to force a dependency check after every fifth 
actual read and storage of channel data (this condition was approved by 
the Laboratory sponsor). 

5. A dependency check is node whenever time is available or forced by 
conditions in 4 as long as there is at least one active dependent 
channel. The set of originally defined dependent channels is scanned 
and, if active, the value of the corresponding independent channel is 
tested with the given conditions and values. If the conditions are met, 
the dependent channel is read, the value is stored, and the proper 
disposition rule is enforced. 

6. Once satisfied, a dependency status may be turned off or let to 
remain cn. When turned off, the dependent channel may be read 
regularly, if desired, and added to the channel schedule file. 
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7. A dependency check for each independent channel can be made only 
between successive actual reads (and storages) for the independent 
channel, and then only once during this span (i.e., multiple dependency 
checks between successive channel reads are not allowed). 

8 . Ml was initially given the value of 10 milliseconds; M2 was given 
the value of 20 milliseconds. Using the algorithm discussed above, the 
program was tested with only a channel schedule file defined. The time 
interval used was 2 milliseconds to force the fastest channel reads 
possible. (This is not optimum because of point 2 above.) The 
following results were recorded: 

Number of Average Time 

Scheduled Channels Between Reads 

1 4.25 msec 

2 8.00 msec 

3 12.00 msec 

4 16.10 msec 

15 50.20 msec 

A channel dependency file (with only one channel defined) was added to 
the above test. If no dependency check has to be made (point 3) , the 
fastest a scheduled channel can be read is reduced to once every 12 
milliseconds. If a dependency check is made but the condition is not 
satisfied (no dependent channel is read), the scheduled channel read is 
further slewed down to once every 14 milliseconds. If the condition is 
met, the rate deteriorates to once every 18 milliseconds. 

Given the statistics above, the values of 10 milliseconds for Ml 
and 20 milliseconds for M2 were retained. 

Control Algorithm . As stated earlier, control of the experiment is a 
rather primitive operation. It is implemented by placing a computed 





digital value into the proper input port of the digital-to-analog 
converter and routing its analog output to the appropriate experiment 
control equipment. Before the actual start of the experiment, this 
digital value is initialized by the operator. This analog voltage 
causes some physical phenomenon to happen, the effect of which is, in 
turn, measurable by an analog-to-digital converter. The output of the 
analog-to-digital converter is monitored via a control channel. 

For proper control of the experiment, the control channel value 
must be within a given range (also operator-defined). If it is not, the 
digital input value to the d/a converter is adjusted up or down 
depending cn which out-of-range condition exists by a certain correction 
value also initialized by the operator. This digital input value is 
continually adjusted until such time that the control channel value is 
within the specified range. If, however, the range is narrow and the 
control channel value skips from one side (of the range) to the other in 
one adjustment, the correction value is halved and (finer) adjustments 
in the opposite direction proceed as before. 

Debug 


The ease of debugging any computer program depends heavily upon how 
the code is written. The use of clever, exotic algorithms tend to 
complicate otherwise sinple programs. And when an error is indicated, 
finding and correcting it can be very frustrating. In the software for 
the portable data acquisition system, this type of algorithms is 
avoided. There is no reason for using such algorithms: the modules 
perform sinple, recognizable functions. 
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Errors do, and did, occur however. But their identification and 


correction was helped tremendously by means of the debugging tools on 
the PDP 11/03 development system. The use of the debugging statement 
indicator (letter D in Fortran statement column 1), and the use of the 
On-Line Debugging Technique (OCT) were the tools most often utilized in 
this project. In addition, numerous input data checking statements were 
added to the code because "debugging input data is as important as 
debugging a program" (Ref 6:87). Strategically located print statements 
of specific error messages were also used abundantly throughout the 
program. 

Test and Integration 


The top-down decomposition technique has one other very practical 
feature: it allows the programmer the ability to use "stub modules". 
These are modules that are written to simulate the functions of 
subordinate nodules. In using this technique, the top module in the 
program is coded and tested using stub modules for all the modules it 
calls. Once the top module has been tested, one of its 
immediate-subordinate modules is coded, the two modules are' integrated 
together along with the necessary stubs, the combination is tested, and 
so forth (Ref 9:147). This technique worked very well in this project 
because the particular format selected to implement the system (at least 
the higher-level portion) is the command format. In this manner, each 
of the next-to-tcp level modules is invoked according to which command 
the user gives interactively with the program. Going further down, each 
of the channel files is created by the respective module also according 
to the type interactively specified by the user. 






Initial test and integration was performed at the PDP 11/03 
development site on those routines not requiring the use of the clock. 
After this portion of the code had been tested and integrated, the 
portable data acquisition system itself was used. A dual floppy disk 
drive, with the RT-11 system floppy disk on one drive and the portable 
system software on the other, was utilized in this test and integration 
phase. An HP 3312A Function Generator was used to generate predictable, 
known signals for input to the analog-to-digital converter. 

Operations and Maintenance 


A program may be subjected to extensive test and integration 
procedures but its real test is hew it holds up in actual practice. The 
portable data acquisition system has been used in two different 
experiments in the Materials Laboratory: high performance liquid 
chromatography and thermal analysis of polymers. In both of these 
experiments, only a few-hundred data points were collected. These data 
points were plotted and oorrpared with strip-chart recordings made 
concurrently with the data acquisition process. The results show a 
general resemblance between corresponding plots: the big difference is 
the presence of intermittent noise spikes on the plots generated by the 
portable system. The noise problem has been reduced significantly since 
then; but it still persists. 

It should be mentioned that the thermal analysis experiment 
required only a straightforward data collection capability. The liquid 
chromatography set-up had two output channels, and they were used as an 
independent-dependent channel pair. There was no real need to collect 
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data cn very short intervals either, so the data collection algorithm 
has not really been "pushed" except during the testing phase. The 
control routines have not yet been exercised on an actual experiment as 
well. Therefore, there has been no occasion so far to perform what can 
truly be considered maintenance programming. When the situation arises, 
the programmer should find anple documentation to make his job easier. 

Summary 

The remaining phases of the software development were discussed in 
this chapter. They appear sinple and straightforward. But this is only 
deceptively so. The efforts put forth in the previous phases make the 
rest of the development job relatively easy. 
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VII. Summary and Recommendations 


The software development effort discussed in this thesis gives one 
the impression of a smooth, ordered transition from one phase to the 
next. Actually, there was a significant amount of overlap between than, 
even a couple of complete iterations from the design of the structure to 
the writing of the code. This is not normally encouraged; the relative 
size of this effort made such iteration possible in this case. 

The software was designed and coded using structured design 
techniques which emphasize modularity of ocuponents. Higher level 
modules are logically broken down into smaller, simpler modules. While 
this technique really does make understanding the software system 
easier, it does tend to increase the size of the program. For this 
project, such increase was minimal but did have an impact on the overall 
scheme of the system. For this size of an effort also, there is a 
normal tendency to view the enphasis on structured programming 
techniques as a nuisance; that these techniques make much more inpact 
on larger systems. However, as has already been mentioned, its 
documentation value alone makes the use of these techniques very 
worthwhile. 

Summary 

The stated purpose of this study was to develop the software for 
the portable, generalized experiment control and data acquisition 
system. By meticulously following the software development phases 
recommended by the Air Force, this software product is now operational 
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and has indeed been used on two Materials Laboratory experiments. The 
results from these experiments show the collected data with a 
significant amount of noise. However, this is recognized as a hardware, 
most probably power supply, problem and does not indicate software 
insufficiency. Any program errors uncovered during the operational 
phase of the software life cycle (which this project is in new) will be 
corrected by the maintenance programmer. 

In addition to the power supply problem briefly mentioned above, 
the project was also delayed considerably during the later stages of the 
development because of the insufficiency of the portable terminal's 
minicassette tapes. It was initially expected that any software written 
for the data acquisition system would fit on one side of a minicassette 
tape. This may have been the case but for the generality of the 
program. The use of structured design techniques may also have added to 
the size of the program. However, it was felt that any drastic cut of 
the program, in terms of its generality and of its structure, would 
seriously inpact the ease of its use and, ultimately, its maintenance. 
In addition, a force fit into one minicassette side leaves no rocm for 
possible enhancements or modifications. If this room is ever needed 
later, for any reason at all, then one is back to contending with the 
same problem. 

In an effort to solve this problem, a program was written to 
"cleanly" break the resulting stand-alone file into two pieces, loading 
each piece into one side of a minicassette tape. Loading the two pieces 
of file from the minicassette tape to the portable data acquisition 
system resulted in numerous loading errors. Using degaussed tapes as 






suggested by the portable terminal manufacturer reduced the number of 
errors; nevertheless, the program load was still unsuccessful. 
Therefore, the initial system requirement bo tie able to load the 
stand-alone program file from the portable terminal's minicassette tapes 
to the data acquisition system was not satisfied. Currently, the 
portable data acquisition system can be used only through the use of a 
dual floppy disk drive, which is the configuration used during the 
testing and initial operational phases of the development. 

Recommendations 

Meaningful recommendations for follow-on efforts to the topics 
considered in this thesis revolve mainly around possible enhancements to 
the system. First of all, since the automatic control algorithm is 
admittedly primitive, a more sophisticated mechanism may be 
incorporated. It must be kept in mind, however, that the system memory 
size is very limited and care must be taken not to incorporate too 
extensive an algorithm. Secondly, there is not new any convenient means 
to abort the program except through the use of the computer RESET 
button. Pressing this button immediately stops the program and resets 
the oonputer. If another experiment run is contemplated, the program 
must be re-loaded. A different abort technique is definitely in order. 
Thirdly, the thermal analysis experiment exposed a deficiency in the 
analog-to-digital conversion method. Previous data collections made 
with an HP coupler-controller/paper tape arrangement show data beyond 
the range selected on the thermal analysis equipment. This means that 
any spikes on the analog input signals are properly and continuously 
recorded. On the portable data acquisition system, any readings outside 
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Appendix A 


Sanple Program Code 

The sanple program codes are given below to provide a feel for what 
the code looks like. In particular, the portion of the oode for the main 
program, GECDAS, is provided to give the reader the details of the channel 
files mentioned in Chapters III and IV. The format for the introductory 
conments for each module is that of Myers, specifically the module 
interface gaecifications. Other comments, along the same lines, are the 
author's. 


PROGRAM GECDAS 
C 

caxxxxraxxxccccaxcccorccaxAXxxarc^^ 

c 

C FUNCTION: THIS IS THE MAIN PROGRAM FOR THE GENERALIZED EXPERIMENT 
C CONTROL AND DATA ACQUISITION SYSTEM (GECDAS). 

C 

C INTERACTIVE COMMANDS ARE: 

C DEFINE - DEFINE DATA COLLECTION CHANNELS 
C HELP - LIST ALL VAID COMMANDS 

C RUN - START EXPERIMENT CONTROL AND DATA ACQUISITION 

C STOP - STOP DATA ACQUISITION PROGRAM 

C 

c. 

c 

C SUBPROGRAMS CALLED: 

C DEFINE - DEFINE DATA COLLECTION CHANNELS 
C HELP - LIST ALL VALID OOC -MANDS 

C RUNEXP - START EXPERIMENT CONfR /' . TATA ACQUISITION 

C 

c. 

c 

C VARIABLES USED: 


C VALID - LOGICAL VARIABLE INDICATING WETHER USER-GIVEN OOt-KAND 
C IS VALID OR NOT (.TRUE. OR .FALSE.) 

C COMAND - USER-GIVEN (ETTERACTIVELY) COMMAND 

C 

c. c 

c C 
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r 


NAMED CDMCN BLOCKS DEFINITION C 

C 

SCDATA (CHANNEL SCHEDULE FILE DATA) : C 

tOIAN - NUMBER CF SCHEDULED CHANNELS C 

ICHAN(I) - THE TTH (SCHEDULED) CHANNEL NUMBER DEFINED C 

KTIME(I,J) - SGIEDULED READ TIME FOR ICIIAN(I) C 

RTIME(1,1) - HOURS COMPONENT CF CHANNEL READ TIME C 

RTIME (1,2) - MINUTES COMPCNdlT OF CHANNEL READ TIME C 

RTIME (1,3) - SECONDS COMPONENT OF CHANNEL READ TIME C 

RTIME(1,4) - MILLISECCNDS COMPONENT OF CHANNEL READ TIME C 

OTIME(I,J) - TIME EITER7AL BETWEEN CHANNEL READS FOR ICHAN(I) C 

OTIME(I,1) - HOURS COMPONENT CF THE TLME INTERVAL C 

DTIME(I,2) - MINUTES COMPONENT CF THE TIME INTERVAL C 

DHME(I,3) - SECONDS COMPONENT OF THE TIME INTERVAL C 

OTIME(I,4) - MILLISECONDS COMPONENT CF THE TIME INTERVAL C 

HDTIME(I,J) - CNE-HALF CF DTE-IE(I,J) , THE TIME INIERVAL C 

SCALE(I) - SCALE FACTOR TOR CHANNEL ICHAN(I) VALUE C 

DNAME(I) - NAME GIVEN TO CHANNEL iaiAN(I) C 

C 

DPDATA (CHANNEL DEPENDENCY FILE DATA): C 

NDCH - NUMBER CF DEPENDENT CHANNELS C 

YCHAN(I) - THE ITH DEPENDENT CHANNEL (NUMBER) DEFINED C 

XCHAN(I) - THE INDEPENDENT GIANNEL FOR YCHAN(I); I.E. , THE C 

CHANNEL UPON WHOSE VALUE YCHAN(I) DEPENDS FOR READING C 
CONDI (I) - TOCETIER WITH VALUE! (I) , IT MAKES UP THE FIRST C 

CONDITION THA XCHAN(I) MUST MEET FOR YCHAN(I) TO C 

BE READ; CAN HAVE VALUES "GT" , "GE", "E Q", "LE", "LT" C 
OOND2(I) ,VALUE2(I) - MAKE UP THE SECOND CONDITION, IF APPLICABLE, C 

THAT XdAN(I) MUST MEET C 

STATUS(I) - INDICATES WHETHER 'THE DEPENDENCY CONDITION FOR C 

YCHAN(I) IS ACTIVE OR NOT C 

DISP(I) - IF THE DEPENDENCY STATUS FOR YCHAN(I) IS ACTIVE At® C 
THE CONDITIONS ARE MET, DISP(I) INDICATES WHETHER TO C 
DEACTIVATE 'HE STATUS OR NOT C 

XCHCHK(I) - A DEPENDENCY CHECK WILL BE MADE ONLY BETWEEN TTO C 

SUCCESSIVE SCHEDULED CHANNEL READS AND THEN ONLY C 

ONCE DURING THIS SPAN; XCHCHK(I) SIGNIFIES, FOR C 

THE CORRESPCt®ING XCHAN(I) , WHETHER A DEPENDENCY C 

CHECK CAN BE LEGALLY MADE OR NOT C 

C 

CNDATA (CHANNEL CONTROL FILE DATA) : C 

NONTL - NUMBER CF CO: TIROL O PANELS C 

OfTLCH(I) - TI!K ITH OCNTPOL CHANNEL (NUMBER) DEFINED C 

LCVALU(I) - LOW LIMIT CF ACCEPTABLE CNTLCH(I) VALUES C 

HIVAUJ(I) - HIGH LLMIT CF ACCEPTABLE QTTrCH(I) VALUES C 

ACTION(I) - INDICATES WHETHER MANUAL OR AUTOMAIC RESPONSE IS C 

TAKEN WHENEVER HIE VALUE OF CNTLCl(I) GETS OUT OF C 
RANGE C 

LOCHAN(I) - MU-IN aTTICH(I) VAIIJE GETS BELCW LOVALU(I) AND C 

ACTION ( I) IS AirOMATIC, LOCHAN(I) IS ADJUSTED C 

ACCORDINGLY C 

HICHAN (I) - MIEN CTTLCH(I) VALUE IS OVER HF/ALU (I) A® ACTION (I) C 
IS AUTOMATIC, ANA ICG OUTPUT CHANNEL HiaiAN(I) IS C 

ADJUST!® AOCORDI NGLY C 
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OLOREL(I) - THE RELATIONSHIP BETWEEN THE LAST CONTROL CHANNEL 
VALUE AND ITS ACCEPTABLE VALUES; HAS ALPHABETIC 
VALUE M OK” IF VALUE WAS WITHIN RANGE; "HI" IF 
LARGER THAN HIVALU(I) ; OR "LO" IF SMALLER THAN 
LOVALU(I) 

DIGITL(J) - ADJUSTMENTS ARE MADE TO LOQIAN(I) OR HICHAN(I) (=J) 
BY LOADING A DIGITAL VALUE (DIGITL(J)) INTO THESE 
CHANNELS WHICH IS THEN CONVERTED TO THE 
CORRESPONDING ANALOG VOLTAGE FOR OUTPUT 
DELTA(I) - THE MAGNITUDE OF THE DIGITAL ADJUSTMENT, EITHER 

ADDED TO OR SUBTRACTED FROM DIGITL(J) ACCORDING TO 
OLDREL(I) 

MESSAG(I,1) - FIRST 8 CHARACTERS OF MESSAGE TO OPERATOR'S 

TERMINAL WHEN CNILCH(I) VALUE IS OUT OF RANGE 
AND ACTION(I) INDICATES MANUAL RESPONSE 
MESSAG(I,2), MESSAG(1,3) - CONTAIN THE REMAINING CHARACTERS OF 

THE MESSAGE TO THE OPERATOR 

CLKCOM (CURRENT CLOCK INFORMATION) 

HR - HOURS COMPONENT CF CURRENT CLOCK TIME 
MIN - MINUTES COMPONENT OF CURRENT CLOCK TIME 
SEC - SECONDS COMPONENT CF CURRENT CLOCK TIME 
MSEC - MILLISECONDS COMPONENT CF CURRENT CLOCK TIME 

ADCOM (ANALOG-TO-DIGITAL CONVERTER VALUES) 

JVALUE - DIGITAL CONVERSION CF ANALOG VOLTAGES PRESENT IN THE 
A/D CHANNELS 


MODULE-MODULE DATA CONNECTION THRCXJCH COMMON BLOCKS 


MODULE 

N A f 

1 E D COHHOl 

• 

1 BLOCK : 


SCDATA 

DPDATA : CNDATA 

CLKCOM 

ADCOM 

GECDAS 

X 

X : X 

X 

X 

HELP 





DEFINE 





SCHFIL 

X 




DEPFIL 


X : 



CONFIL 


; X 



RSLINE 

X 




DVTIME 





DELETE 





RDLINE 


X : 



DEFALT 





rcl^t: 


: X 



RUNEXP 

X 

X ; X 



PARAMS 





RT11 





INITPT 





RUNID 
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SIGNAL 





STQPTN 





INITCV 


: X 



SEICLK 


• 

• 

X 


CLKINT 


• 

X 


RSCHAN 

X 




CHKDEP 


X : 


X 

UPCHAN 

X 


X 

X 

OONEXP 


: X 



DAC 





STORE 





SNQATA 





GETTIM 



X 


READCH 




X 

ADC 




X 

ADAC 





SAVE 

X 



X 

UPDATR 

X 




AOTIME 






C 

C 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


*★★*★★*★•*★★*★*★★**★********★***★★★★★★*★★*★★★★★★★★★★★*★★* **★★*★*★★★*★★* 


LOGICAL*1 VALID 
REAL*8 CQMAND 


C 


C 


c 

c 

c 


c 


JNTEGER*2 NCHAN,ICHAN(16),RTIME(16,4),OTIME(16,4),HETTIME(16,4) 
REAL*8 DNAME(16) 

REAL*4 SCALE(16) 

LOGICAL*1 XCHCHK(16) 

DOTEGER*2 NDCH,YCKAN(16) ,XCHAN(16) ,CONDI(16) ,COND2(16) , 

1 STATUS(16) 

REAL*4 VALUE1(16),VALUE2(16),DISP(16) 

INTEGER*2 NCNTL,CITOTH(16) ,LOCHAN( 16) ,HICHAN(16) , 

INTEGER*2 OLDREL(16),DIGITL(2),DELTA{16) 

REAL*8 ACTION (16),MESSAG(16,3) 

REAL*4 L0VALU(16),HIVALU(16) 

INTEGER*2 HR,MIN,SEC,MSEC 


INroGER*2 JVALUE(16) 


COMMON 

coiswon 

l 

COM40N 

1 

COMMON 

C0M40N 


/SGDATA/ MCHAN, ICHAN, RTIME,DTD4E, HOTIME, SCALE,DNAME 
/DPDATA/ NDCH,YCFAN,XGIAN,CONDI,OCND2,DISP, 

VALUE1,VALUE2,STATUS,XGICHK 
/CNDAT A/ NCNTL, G 7 LOTI I, ACT ION, LOG IAN, HIQ IAN, MESS .AG, 
LUVALU,HIVALU,OLDREL,DIGITL,DELTA 
/CLKCOM/ HR,MIN,SEC,MSEC 
/ADCOM/ JVALUE 
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non 


C 


CALL HELP(VALID) 


NCHAN = 0 
NDCH = 0 
NCNTL = 0 


GET COMMAND 

100 WRITE(5,1001) 

1001 FORMAT(/2X,"COMMAND? ',$) 

C 

READ(5,1002,ERR=200) COMAND 

1002 FORMAT(A8) 

C 

VALID = .FALSE. 

IF (OOMAND. EQ.4HHELP) CALL HELP(VALID) 

IF (COMAND.EQ.6HDEFINE) CALL DEFINE(VALID) 

IF (COMAND. EQ.3HRUN) CALL RUNEXP (VALID) 

IF (COMAND.BQ.STOP) GOTO 900 

C 

IF (.NOT.VALID) WRITE(5,1003) 

1003 FORMAT(/2X,'INVAID OOf'MAND; NO COMMAND EXECUTED. ') 
GOTO 100 

C 

200 WRITE(5,2001) 

2001 FORMAT(/2X/*ERROR - INVALID INPUT; TRY AGAIN.') 

GOTO 100 
C 

900 CONTINUE 
C 

STOP 

END 
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SUBROUTINE SNDATA {TODAY, EXP ID, OPERTR, RDTIME, CHANEL, VALUE, NDATA) 


C 

(^************************************★******************************£ 


C C 

C FUNCTION: WRITE RUN INFO AND COLLECTED DATA ONTO MINICASSETTE C 

C c 

C CALLING SEQUENCE: CALL SNDATA(TODAY,EXPID,OPERTR, C 

C RDTIME,CHANEL,VALUE,NDATA) C 

C C 

C INPUTS: C 

C TODAY - TODAY'S DATE C 

C EXPID - EXPERIMENT IDENTIFICATION C 

C OPERTR - OPERATOR'S LAST NAME C 

C RDTIME - CHANNEL READ TIME C 

C CHANEL - CHANNEL NUMBER C 

C VALUE - SCALED CHANNEL VALUE C 

C NDATA - NUMBER CF DATA POINTS C 

c c 

C OUTPUTS: NONE C 

c c 

C EXTERNAL EFFECTS: C 

C COLLECTED DATA ARE WRITTEN ONTO THE TERMINAL MINICASSETTE C 

C C 

C.C 

C C 

C CALLED BY: C 

C STORE - STORE DATA IN TERMINAL'S MINICASSETTE C 

C C 

C SUBPROGRAMS CALLED: NONE C 

C C 

C VARIABLES USED: C 

C TODAY - TODAY'S DATE C 

C EXPID - EXPERIMENT IDENTIFICATION C 

C OPERTR - OPERATOR'S LAST NAME C 

C RDTIME - RECORDED CHANNEL READ TIME C 

C CHANEL - CHANNEL NUMBER C 

C VALUE - SCALED CHANNEL VALUE C 

C NDATA - NUMBER OF DATA POINTS TO WRITE ONTO MINICASSETTE C 

C C 


£★★★***★************************* ****•****■*•*★★■**■*■*★*★**★★*★★■**★**★★★•**£ 


INTEGER*2 RDTD-1E( 1175,4) ,CHANEL(1175) ,NDATA 
REAL*4 VALUE(1175) 

REAL*L TODAY,EXPID(2),OPERTR 

C 

C.WRITE RUN IDENTIFICATION 

r 

WRITE(5,1001) EXPID(1),EXPID(2) 

1001 FORMAT (/2X,'EXPERIMENT: ', 2A8) 

C 

WRITE(5,1002) OPERTR,TODAY 

1002 FORMAT(2X,'OPERATOR: ',A8,' DATE: ',A8) 

C 

C.WRITE DATA ONTO MINICASSETTE 









c 

WRITE(5,1003) 

1003 FORMAT(/2X, - HMSMCH VAUJE") 

DO 200 I=1,NDATA 

WRITE{5,1004) (RDTIME(I,J) ,J=1,4) ,CHANEL(I) .VALUE(I) 

1004 FORMAT(IX,14,212,13,12,F8.2) 

200 CONTINUE 

C 

RETURN 

END 
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Appendix B 
Users Manual 


Introduction 


The objective of the Users Manual is to provide non-ADP personnel 
with the information necessary to effectively use the system (Ref ). 
However, because of the interactive nature of the input requirements for 
the program, the Users Manual for the portable data acquisition software 
is very much sinplified. As shown in the next sections, the Users 
Manual is nothing more than a list of suggestions on how to get the most 
out of the system. 

Input Formats 

Input formats are made explicit by system pronpts and headings. An 
"A" format requires an alphabetic entry; an "N", a numeric entry; and 
an "X", an alphabetic or a numeric entry. Line entries are titled so 
that required information nay be typed underneath the respective 
heading. For exairple (user entries are underlined) : 


CH 

CHANNEL 

SCALE 

START : 

READ 

TIME 

TIME 

INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN 

SEC 

MSEC 

HR MIN 

SEC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN NN 

NN 

NNN 

NN NN 

NN NNN 

> 1 

CHI 

1 . 





5 

> 2 

CH2 







> 3 

CH3 







> 4 

CH4 








> 
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This line entry results in (see Appendix C for more examples): 


CH 

CHANNEL 

SCALE 

START : 

READ TIME 

TIME : 

INTERVAL 

* 

DATA NAME 

FACTOR 

HR MIN 

SEC 

MSEC 

HR MIN 

SEC 

MSEC 

1 

CHI 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

2 

CH2 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

3 

CH3 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

4 

CH4 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 


Here, one of the most powerful features of the system is revealed. 
After defining the first channel fully, the user need not do the same 
for the other channels. The redundant information about the start read 


time and the time interval is omitted. By defaulting to the values of 
the previous channel, the system automatically assigns the same values 
to the channels down the line. This automatic default to the previous 
channel's value occurs only, however, for values in an incomplete entry 


line. 

For example: 





CH 

CHANNEL 

SCALE 

START READ TIME 

TIME 

INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN SEC MSEC 

HR MTN 

SEC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN NN NN 

NNN 

NN NN 

NN NNN 

> 1 

CHI 

1.0 

1 1 



500 

> 2 

CH2 

1.0 




2 

> 3 


2.0 

5 




> 

would 

result in: 






CH 

CHANNEL 

SCALE 

START READ 

TIME 

TIME 

INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN SEC 

MSEC 

HR MIN 

SEC MSEC 

1 

CHI 

1.00 

Oil 

0 

0 0 

0 500 

2 

CH2 

1.00 

0 0 0 

0 

0 0 

2 0 

3 


2.00 

0 0 5 

0 

0 0 

2 0 


Other user entries are not as complicated and, as already stated, 
properly prompted by the system. In addition, the system echoes all 
pertinent input values to give the user a chance to double-check his 
information before proceeding. For inputs requiring specific entries, a 
list of possible valid entries is provided. The program will not 
proceed to the next executable statement unless one of the valid entries 
is received. 
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Output Format 


The output of the system is the collected data dumped into the 
terminal minicassette tape- Each time a dunp to the minicassette is 
indicated, the proper run identification is placed in front of the data. 
This run information includes the experiment identification, the date, 
and the operator's last name. The data is written in the format 
hhhhmmsskkknnxxxxx.xx; where hhhhmmsskkk refers to the time the data 
was recorded in hours (hhhh), minutes (mm), seconds (ss), and 
milliseconds (kkk); nn is the channel number; and xxxxx.xx is the 
scaled channel value. 

Channel Numbering 

The portable data acquisition system accepts, as inputs, both 
low-level (millivolts range) and high-level (~10v to +10v) signals from 
loboratory equipments. The high-level signals are connected directly to 
the analog-to-digital converter. The low-level signals are multiplexed 
and amplified before they are fed to the converter. The output of the 
anplifier is permanently connected to channel 0 (defined as channel 1 in 
the program) of the converter. Therefore, no high-level signal can be 
defined as channel 1 in the program. 

If there are more than one low-level signals, the channels are 
numbered 1 to N, where N is the number of low-level signals to be 
monitored. High-level signals, if present, are then numbered N+l to 
N+M, where M is the number of high-level signals. If only high-level 
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signals are to be monitored, they must be numbered 2 to M+l. 


Channel Naming 

Provision was made in the program for the capability to measuLe 
rates (of change per unit time). To do this, the user sirrply uses the 
word "RATE" as the first four letters of the particular channel's data 
name. The value stored for this channel is properly ocxrputed to depict 
its change in value per second. Heat up rates and rate of crack growth 
are typical measurements being made in the laboratory. 

General Hints 


Scale factors can be used bo good advantage by realizing that the 
analog-to-digital input range of -10 volts to +10 volts produces a 
digital conversion of -2048 to 2047. The digital value multiplied by 
4.88 gives the signal level in millivolts. 

If, for seme reason or another, a need arises to monitor a certain 
signal with two channels, the user is reminded that it is perfectly 
legal to do so. Using two different, judiciously selected scale 
factors, one can monitor actual values and rates at the same time. 



appendix C 
Sanple Session 


Hie following "printout" is transcribed fran a sample session at the 
operator's terminal after all the necessary channel connections between the 
portable data acquisition system and the experiment equipments have been made. 
The underlined wards or letters are user entries. Small letters enclosed in 
parentheses are provided in serve instances for clarification. 


THE FOLLOWING IS A LIST CF VALID COMMANDS 

HELP - LIST ALL VALID COMMANDS 
DEFINE - DEFINE CHANNELS TO BE USED 

(NORMALLY, THE FIRST COMMAND GIVEN) 
RUN - START DATA ACQUISITION PROCESS 

(GIVEN ArTER ALL CHANNELS ARE DEFINED) 
STOP - STOP THE PROGRAM 


COPLAND? DEFINE 

(S)CHEDOLE, (D)EPENDENCY, OR (C)ONTROL FILE? OR (Q)UIT? S 


CH 
# 
NN 
> 1 

CHANNEL SCALE 

DATA NAME FACTOR 
XXXXXXXX ■ NNNN.NN 
CHI 1.0 

START READ TIME 
FIR MIN SEC MSEC 
NN NN NN NNN 

TIME INTERVAL 
HR MIN SEC MSEC 
NN NN NN NNN 
5 

> 2 

CH2 



> 3 

CH3 



> 4 

CH4 




>(here, the operator hits the carriage return key immediately.) 


THE FOLLOWING INFORMATION WAS SUPPLIED: 


CH 

CHANNEL 

SCALE 

START : 

READ 

TIME 

TIME : 

INTERVAL 

# 

DATA NAME 

FACTOR 

HR 

MIN 

SEC 

MSEC 

HR MIN 

SBC 

MSEC 

1 

CHI 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

2 

CH2 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

3 

CH3 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

4 

CH4 

1.00 

0 

0 

0 

0 

0 

0 

5 

0 

ANY CHANGES (Y/N) 

? Y 









CHANGE ALL (CA), 

LOCAL (CL) 

, ADD 

(AD) 

, DELETE 

(DL) 

i 

OR 

(Q)UIT? 


CHANNEL? 4 


CHANNEL? 1 
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/* 

J 


CHANNEL? (immediate carriage return) 
THE FOLLOWING INFORMATION WAS SUPPLIED: 


CH 

CHANNEL 

SCALE 

START READ TIME 

TIME INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN SEC MSEC 

HR MIN SEC MSEC 

3 

CH3 

1.00 

0 0 0 0 

0 0 5 0 

2 

CH2 

1.00 

0 0 0 0 

0 0 5 0 

ANY 

CHANGES (Y/N) 

? Y 



CHANGE ALL (CA), 

LOCAL (CL) 

, ADD (AD), DELETE (DL), OR (Q)UIT? CL 

CH 

CHANNEL 

SCALE 

START READ TIME 

TIME INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN SEC MSEC 

HR MIN SEC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN NN NN NNN 

NN NN NN NNN 

> 2 

CH2 

1.0 

1 

100 

>(inmediate carriage return) 


THE 

FOLLOWING INFORMATION WAS SUPPLIED: 


CH 

CHANNEL 

SCALE 

START READ TIME 

TIME INTERVAL 

# 

DATA NAME 

FACTOR 

HR MIN SEC MSEC 

HR MIN SEC MSEC 

3 

CH3 

1.00 

0 0 0 0 

0 0 5 0 

2 

CH2 

1.00 

0 0 10 

0 0 0 100 

ANY CHANGES (Y/N) 

? Y 



CHANGE ALL (CA), 

LOCAL (CL) 

, ADD (AD), DELETE (DL) r OR (Q)UIT? AD 

CH 

CHANNEL 

SCALE 

START READ TIME 

TIME INTERVAL 

f 

DATA NAME 

FACTOR 

HR MIN SBC MSEC 

HR MIN SEC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN NN NN NNN 

NN NN NN NNN 

> 1 

CHI 





>(inmediate carriage return) 


THE FOLLOWING INFORMATION WAS SUPPLIED: 


CH 

CHANNEL 

SCALE 

START READ TIME 

TIME 

INTERVAL 

* 

DATA NAME 

FACTOR 

HR 

MIN SEC MSEC 

HR MIN 

SEC MSEC 

3 

CH3 

1.00 

0 

0 0 0 

0 0 

5 0 

2 

CH2 

1.00 

0 

0 10 

0 0 

0 100 

1 

CHI 

1.00 

0 

0 10 

0 0 

0 100 

ANY 

CHANGES (Y/N) 

? Y 





CHANGE ALL (CA), 

LOCAL (CL) 

, ADD (AD), DELETE (DL), 

OR (Q)UIT? CA 

CH 

CHANNEL 

SCALE 

START READ TIME 

TIME 

INTERVAL 

# 

DATA NAME 

FACTOR 

HR 

MIN SEC MSEC 

HR MIN 

SEC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN 

NN NN NNN 

NN NN 

NN NNN 

> 1 

TEMP1A 

4.88 


1 


1 500 

> 2 

TEMP IB 

4.88 


2 


2 

> 3 

TEMP 1C 

4.88 

24 




> 4 

TEMPID 

4.88 

48 




> 5 

IENGTH 

1.0 


1 


10 
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> 6 RATE _ 6.0 

>(inmediate carriage return) 

THE FOLLOWING INFORMATION WAS SUPPLIED: 


CH 

CHANNEL 

SCALE 

START 1 

READ 

TIME 

TIME : 

INTERVAL 

t 

DATA NAME 

FACTOR 

HR MIN 

SEC MSEC 

HR MIN 

SEC 

MSEC 

1 

TEMP 1A 

4.88 

0 

0 

1 

0 

0 

0 

1 

500 

2 

UMP1B 

4.88 

0 

0 

2 

0 

0 

0 

2 

0 

3 

TEMPlC 

4.88 

24 

0 

2 

0 

0 

0 

2 

0 

4 

TEMP ID 

4.88 

48 

0 

2 

0 

0 

0 

2 

0 

5 

LENGTH 

1.00 

0 

1 

0 

0 

0 

0 

10 

0 

6 

RATE 

6.00 

0 

1 

0 

0 

0 

0 

10 

0 


ANY CHANGES (Y/N)? N 
COMMAND? DEFINE 


(S)CHEDULE, (D) EPENDENCY, OR (C)ONTROL FILE? OR (Q)UIT? D 


DEP 

CHANNEL 

SCALE 

IND 

OOND 

COND 



TIME INTERVAL 

CH 

DATA NAME 

FACTOR 

CH 

1 

VALUEl 

2 

VALQE2 

DISP 

HR MIN SBC MSEC 

NN 

XXXXXXXX 

NNNN.NN 

NN 

AA 

NNNN.NN 

AA 

NNNN.NN 

AAA 

NN NN NN NNN 

> 7 

TEMP2 

4.88 

1 

GT 

500.00 

LT 

525.00 

ON 


> 8 

TEMP3 

4.88 

3 

GE 

1200.00 

LE 

1212.00 

OFF 

0 0 1 500 


>(inmediate carriage return) 


THE FOLLOWING INFORMATION WAS SUPPLIED: 


DEP CHANNEL 

SCALE 

IND OOND 


COND 



TIME 

INTERVAL 

CH DATA NAME 

FACTOR 

CH 

1 

VALUEl 

2 

VALUE2 

DISP 

HR MIN 

SEC MSEC 

7 TEMP 2 

4.88 

1 

GT 

500.00 

LT 

525.00 

ON 



8 TEMP3 

4.88 

3 

GE 

1200.00 

LE 

1212.00 

OFF 

0 J 

1 500 

ANY CHANGES (Y/N)? Y 









CHANGE ALL (CA) 

, LOCAL 

(CL) , 

ADD 

(AD), DELETE 

(DL) , OR 

(Q) UIT 

' ? 2 



ANY CHANGES (Y/N)? N 


COMMAND? DEFINE 


(S)CHEDULE, (D)EPENDENCY, OR (C)ONTRDL FILE? OR (Q)UIT? C 


CTL 

CONTROL CHANNEL 

ACTION IF 

OUTPUT CH 

IF OPERATOR 

ACTION 

REQUIRED, 

CH 

OK IF WITHIN 

OUT OF RANGE 

IF CTL CH 

ENTER MESSAGE TO OPERATOR 

* 

VALUEl 

TO VALUE2 

(OPER/OUTPUT) 

LOW 

HIGH 

(OPER TYPES 

"C" TO 

CONTINUE) 

NN 

NNNN.NN 

- NNNN.NN 

AAAAA 

NN 

NN 

AAAAAAAAAAAAAAAAAAAAAAAA 

> 4 

350.00 

360.00 

OPER 



CHANNEL 1 

OUT OF 

RANGE!! 

> 6 

35.00 

3.5 

OUTPUT’ 

1 

2 





>(immediate carriage return) 
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THE FOLLOWING INFORMATION WAS SUPPLIED: 


CTL CONTROL CHANNEL 
CH OK IF WITHIN 
# VALUE1 TO VALUE2 

4 350.00 360.00 

6 35.00 3.50 


ACTION IF 
CUT CF RANGE 
(OPER/GUTPUT) 
OPER 
OUTPUT 


OUTPUT CH IF OPERATOR ACTION REQUIRED, 
IF CTL CH ENTER MESSAGE TO OPERATOR 
LOW HIGH (OPER TYPES "C" TO CONTINUE) 
CHANNEL 1 CUT CF RANGE!! 

1 2 


ANY CHANGES (Y/N)? N 
OOfMAND? HJN 

ARE YOU RUNNING RT-11? (Y/N)...Y 

ENTER TODAY'S DATE (DDWMYY, 20FEB81) ... 22FEB81 

ENTER EXPERIMENT ID (16 CHAR MAXIMUM).. . MECHANICAL TEST 

ENTER OPERATOR LAST NAME (8 CHAR MAXIMUM) ... ILORETA 

ENTER NIMBER OF SIGNALS TO BE AMPLIFIED (MAX, 16) : N-flJX = 5 
IS 5 OK? (Y/N).. .N 

ENTER NLMBER CF SIGNALS TO BE AMPLIFIED (MAX, 16) : NUMX = 4 
IS 4 OK? (Y/N)...Y 

ENTER NIMBER OF SIGNALS THAT NEED NO AMPLIFICATION (<16-NMUX) : 2 
IS 2 OK? (Y/N)...Y 

ENTER STOP OPTION (DATA OR TIME) : DATA 

ENTER NLMBER CF DATA POINTS TO BE COLLECTED: 3000 
IS 3000 OK? (Y/N)...Y 


ENTER NUMBER CF DATA POINTS PER DUMP TO THE MINICASSETTE (MAX, 1100) : 1100 
IS 1100 CK? (Y/N)...N 


ENTER NUMBER CF DATA POINTS PER DUMP TO THE MINICASSETTE (MAX, 1100) : 500 
IS 500 CK? (Y/N)... Y 


***MAKE SURE MINICASSETTE IS SET FOR WRITING!!! 
***TURN THE SYSTEM CLOCK ON!!! 


ENTER 'GO' TO START THE DATA ACQUISITION PROCESS: GO 

As soon as the operator hits the return key, the data gathering process is 
started. At this point, he may turn the printer on his terminal CFF. For 
this particular exanple session, however, he should not because of his 
possible interaction when a control channel gets out of range. Assuming the 
experiment runs to oorrpletion and the printer is CN when a dunp to the 


81 


1 


minicassette tape is indicated, the following header and exanple data may be 
printed: 

EXPERIMENT: MECHANICAL TEST 
OPERATOR: ILOREIA DATE: 22FEB81 


HMSMCH VALUE 
0 0 0991 1 537.52 
0 0 1991 2 323.48 
0 0 2491 1 525.74 
0 0 3991 1 520.85 
0 0 3991 2 330.95 
004 51 518.26 

004 57 152.47 
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